home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Magnum One
/
Magnum One (Mid-American Digital) (Disc Manufacturing).iso
/
d21
/
dvmam11.arc
/
DVMAM.DOC
< prev
next >
Wrap
Text File
|
1990-11-24
|
36KB
|
925 lines
Dynamic-Virtual Memory Allocation Manager (tm)
DVMAM (tm)
Version 1.10
Copyright 1990 R.C.B. Enterprises
Turbo C version
October 8th, 1990
Table of contents
-----------------
Page
What is Shareware.......................................... 1
Disclaimer of warranty..................................... 1,2
Trademarks................................................. 2
What should I have received with DVMAM?.................... 2
So then, what is DVMAM?.................................... 2
How does DVMAM function?................................... 3
So what are the memory limits?............................. 3,4
Important considerations for memory allocation............. 4,5
A. Extended memory....................................... 4
B. Expanded memory....................................... 5
What are the functions that I can use in my system?........ 5-9
A. Extended memory functions............................. 5,6
I. alloc_ext........................................ 5
II. dealloc_ext...................................... 5
III. save_ext......................................... 5
IV. load_ext......................................... 5,6
V. kbytes_ext....................................... 6
VI. ext_free......................................... 6
VII. cpu_type......................................... 6
VIII. ext_setup........................................ 6
B. Expanded memory functions............................. 6,7
I. alloc_ems........................................ 6
II. dealloc_ems...................................... 6
III. save_ems......................................... 7
IV. load_ems......................................... 7
V. pages_ems........................................ 7
VI. ems_installed.................................... 7
C. DVMAM controller functions............................ 7-9
I. alloc_mem........................................ 7
II. dealloc_mem...................................... 7,8
III. save_memory...................................... 8
IV. load_memory...................................... 8
V. bytes_available.................................. 8
VI. bytes_total...................................... 8
VII. set_memory_usage................................. 8,9
VIII. memory_setup..................................... 9
IX. memory_shutdown.................................. 9
How do I link the DVMAM library into my program?........... 9,10
A. TURBO C projects...................................... 9
B. TURBO C command-line compiler......................... 9,10
C. TLINK................................................. 10
Thanks..................................................... 11
Version 1.10 release....................................... 11
Registration form.......................................... 12 (unlabeled)
I
What is Shareware?
------------------
Shareware distribution gives users a chance to try software before
purchasing it. If you try a Shareware program and continue using it, you
are expected to register that program. Individual programs differ on the
details. Some programs request registration while others require it and
others allow an optional maximum trial period that the program may be
freely used before registration is required. With the registration you may
receive only the right to continue to use that product to a full blown
version of the program with printed manual and source code.
Copyright laws apply both to Shareware and commercial software and the
copyright holder retains all rights with a few specific exceptions stated
below. Shareware authors are accomplished programmers just like commercial
authors and the programs are of comparable quality. (In both cases there
are good programs and bad programs.) The main difference is in the method
of distribution. The author specifically grants the right to copy and
distribute the software either to all or a specific group. For example,
some authors require written permission before a commercial disk vendor may
copy their software.
Shareware is a distribution method, not a type of software. You should
find software that suits your needs and pocketbook whether it's commercial
or Shareware. The Shareware system makes fitting your needs easier because
you can try the software before you purchase the software. And because the
overhead of producing the program is low, prices are also low (in most
cases). Shareware has the ultimate money-back guarantee.. If you don't use
the product, don't pay for it.
Disclaimer of Warranty
----------------------
The DVMAM program and manual are sold "as is" and without warranties
as to performance of merchantability or any other warranties whether
expressed or implied. Because of the various hardware and software
environments into which the program may be put, no warranty of fitness for
a particular purpose is offered. The user must assume the entire risk of
using the program. Any liability of the seller will be limited exclusively
to product replacement or refund of purchase price. R.C.B. Enterprises
assumes no liability for damages, direct or consequential, which may result
from the use of DVMAM.
DVMAM is a Shareware program and is provided at no charge to the user
for evaluation. Feel free to share it with your friends provided it is not
altered or as part of another system. If you find DVMAM useful and continue
to use DVMAM after a 30 day trial period, a registration payment of $35 is
required. The $35 registration fee will license one copy for use on any one
computer at a time.
Anyone distributing DVMAM for any kind of remuneration must first
contact R.C.B. Enterprises for authorization.
Page 1
You are encouraged to pass a copy of DVMAM along to your friends for
evaluation. Please encourage them to register their copy if they find that
they can use it. All registered users will receive the latest copy of DVMAM
in all memory models supported by the requested compiler version, the
ability to access all available memory (if you're a Turbo Pascal user), and
a bound printed manual.
Compilers currently supported as of this release are Turbo Pascal 4.0
thru 5.5, Turbo C 2.0 and Microsoft C 5.0 and higher. The registration fee
of $35 is the same for all versions of DVMAM. The source (Assembler and C
for TURBO C and Microsoft C, Assembler and Pascal for TURBO PASCAL) is
available with DVMAM for $50 (this includes the source and the latest
release of DVMAM). Please remember to specify compiler when you register.
Trademarks
----------
Before we continue, we need to cover trademarks so the appropriate
companies receive credit.
Microsoft is a registered trademark of Microsoft corporation
IBM is a trademark of International Business Machines
TURBO Pascal and TURBO C are trademarks of Borland International
Dynamic-Virtual Memory Allocation Manager and DVMAM are trademarks of
R.C.B. Enterprises
LIM is a trademark of Lotus-Intel-Microsoft corporations
What should I have received with DVMAM?
---------------------------------------
With the Shareware version of DVMAM you should have received the
following files:
DVMAM.DOC - This is this file
DVMAMSTC.LIB - Library containing the small model for Turbo C
DVMAM.H - Turbo C include file
DV_TEST.C - A test program that shows memory allocation in action
DV_REG.TXT - A simple registration form for DVMAM. This form is
also found at the end of this document.
DV_BUG.TXT - A bug report form for DVMAM - hopefully this will
never be used.
DV_PRINT.BAT - A small batch file that prints this file.
README.1ST - A small file describing DV_PRINT and also contains a
list of these files.
So then, what is DVMAM?
-----------------------
The Dynamic-Virtual Memory Allocation Manager uses conventional,
extended and expanded memory in your computer to allow your programs to
access up to 24 megabytes of memory. This memory, which on most systems is
used only for RAM disks or print spoolers, can now be used effectively for
any application as though it was conventional memory by using the DVMAM
system.
Page 2
How does DVMAM function?
------------------------
DVMAM uses a main set of generalized functions to control specific
functions focused at specific memory types. DVMAM is capable of allocating
memory to a specific memory type or over all memory available in the system
your program is being executed in.
Once memory has been allocated (reserved for future use), its
information is stored in memory to be used by DVMAM in the future and a
block identification number is returned to the user. This number must be
saved in order to use the memory just allocated. The maximum amount of
space that can be allocated to one block is 64k bytes (or 65536 bytes).
In order to use this memory a data transfer area is established by
DVMAM to operate as a medium between the normal C functions and DVMAM.
dvmam_dta is declared as a far pointer by DVMAM and serves as this transfer
area. A specific amount of memory is reserved for dvmam_dta when DVMAM is
initialized with a function called "memory_setup". The amount of memory
reserved for dvmam_dta is specified by the user and should be no larger
than the largest block you intend to allocate. If it is larger, precious
bytes will be reserved and never used. As with the largest possible block
size being 64k, the largest size of dvmam_dta is also 64k.
Once dvmam_dta has been set, the contents stored in the memory
location used by dvmam_dta may be saved with a function called
"save_memory". The block identification number is passed to the function
and the appropriate memory type, size and location is determined. The
contents of dvmam_dta is then transferred into that location.
Similar to the function above that saves information, "load_memory"
will load data in from a specific memory location into dvmam_dta. NOTE:
DVMAM does not check to see if the contents of DVMAM have been changed and
not saved. Once a call to "load_memory" has been made the data in dvmam_dta
will be destroyed as new data replaces it.
So what are the memory limits?
------------------------------
Each memory type has specific limits. Conventional memory is available
on all machines. The amount of memory that may be used is dependent on the
size of the programs loaded into memory. So naturally a program occupying
128k of memory will leave more available than a program occupying 384k of
memory. The limit on conventional memory is 640k and all programs executed
will take up some or all of conventional memory. With new innovations in
computing, more and more specialized drivers and TSR (Terminate-Stay
Resident) programs are storing the majority of their information in
extended memory and freeing more conventional memory to be used by larger,
more memory intensive programs. This is important in many cases because the
majority of programs currently do not support either extended or expanded
memory.
LIM EMS (expanded memory) supports up to 8 megabytes of memory. This
Page 3
memory is governed throughout the system by a driver known as an EMM driver
(Expanded Memory Manager). The EMM keeps track of memory that has been
allocated and that which hasn't. Since the EMM uses a separate external
driver, other programs are able to allocate expanded memory and not
interfere with each other. DVMAM, before attempting to allocate expanded
memory, first checks to see if the EMM has been installed.
If an EMM has not been installed, DVMAM will make no attempt to
allocate expanded memory. This is done at run-time, not during link time,
so a program that supports expanded memory will make use of it when it is
available. DVMAM requires an EMM that supports the LIM EMS standard version
3.2 or higher.
Extended memory is memory directly supported by the microprocessor and
supports up to 16 more megabytes of memory. Only 80286 machines and their
successors (such as the 80386 and 80486) support extended memory. Machines
such as 8086 and 8088 do not support extended memory. DVMAM, before
attempting to allocate extended memory, first checks the microprocessor
type.
If a '286 or higher is not in use, DVMAM will make no attempt to
allocate extended memory. This action, as with checking for the EMM, is
done at run-type and not link time. A program that supports extended memory
will only make use of it when it is available.
Important considerations for memory allocation
----------------------------------------------
Extended memory
---------------
There is no way to tell if another program is using extended memory so
its usage should be optional unless it is run in a single program
environment. In other words, if extended memory is available and it is
known that no other programs are making use of extended memory, it is
entirely safe to use. However, if other programs (such as RAM disks, print
spoolers or disk cache programs) are running in the system along with the
main application, data allocated to your program will more than likely
destroy data in extended memory being used by those sorts of programs. So
making extended memory optional is advised.
If you are considering an interrupt intensive program (such as
networking, communications or other programs that make heavy use of
interrupts or are dependant on interrupts), extended memory should be
avoided.
Each time data is moved to or from extended memory, interrupt
processing is halted. A few examples of the effects of extensive extended
memory moves are: 1. If characters are coming in through your serial port,
or through a network interface, during an extended memory move those
characters will be lost. 2. Characters typed at the keyboard may be skipped
during a move. 3. If usage is extensive enough, one or more seconds may be
lost by the system clock.
Page 4
Expanded memory (EMS)
---------------------
If expanded memory is in use it must be noted that the EMM will
allocate 16k chunks. It is important to consider this when allocating
expanded memory. If only 4k is needed and 256k of expanded memory is
available, under normal circumstances it would be appropriate to assume
that 64 blocks of memory could be allocated. Since 16k blocks are allocated
at a time, only 16 blocks would be used and 12k of memory per block would
be wasted.
Expanded memory is also different from the other types of memory in
that it uses a separate, external driver to control the expanded memory.
Memory allocated to the EMM is kept allocated and assumed it is still in
use by your program long after your program may have finished executing.
This makes it unavailable for use by other programs in the future that may
make use of expanded memory. It is then extremely important to deallocate
all expanded memory before terminating your program.
What are the functions that I can use in my system?
---------------------------------------------------
Extended memory functions
-------------------------
The extended memory functions control all extended memory available in
the system.
Function name: alloc_ext
Prototype: int alloc_ext(int size);
Use: alloc_ext attempts to allocate memory of <size> bytes.
alloc_ext returns the handle of the memory allocated or
-1 if the attempt to allocate memory failed.
Function name: dealloc_ext
Prototype: int dealloc_ext(int handle);
Use: dealloc_ext frees the memory specified by the block
identifier. Be deallocating memory, it is once again made
available and can be allocated again later in the
program. dealloc_ext returns 0 on success, -1 on failure.
Function name: save_ext
Prototype: int save_ext(int handle, void far * buffer);
Use: save_ext moves data from the location specified by buffer
into the memory location specified by handle. save_ext
returns 0 on success, -1 on failure.
Function name: load_ext
Prototype: int load_ext(int handle, void far * buffer);
Page 5
Use: load_ext moves data from the memory location specified by
handle into the location at buffer. load_ext returns 0
on success, -1 on failure.
Function name: kbytes_ext
Prototype: int kbytes_ext(void);
Use: kbytes_ext returns the total amount of memory (in kbytes)
available as extended memory.
Function name: ext_free
Prototype: long ext_free(void);
Use: ext_free returns the amount of extended memory in bytes
available to be allocated.
Function name: cpu_type
Prototype: int cpu_type(void);
Use: cpu_type returns the type of microprocessor available on
the system DVMAM is currently being used on. Possible
return types are: 86 for 8086 and 8088 systems, 186 for
80186, 286 for 80286 and 386 for 80386 systems.
Function name: ext_setup
Prototype: void ext_setup(void);
Use: ext_setup prepares all structures and data used by DVMAM
for extended memory allocation.
Expanded memory functions
-------------------------
The expanded memory functions control all expanded memory available in
the system.
Function name: alloc_ems
Prototype: int alloc_ems(int size);
Use: alloc_ems attempts to allocate expanded memory via the
EMM. alloc_ems returns the handle to expanded memory,
-1 the attempt to allocate memory failed.
Function name: dealloc_ems
Prototype: int dealloc_ems(int handle);
Use: dealloc_ems frees the memory specified by handle via the
EMM. This memory is then made available for use later in
program execution or by other programs which may use
expanded memory. dealloc_ems returns a 0 if the memory
has been successfully deallocated, -1 if the function
failed.
Page 6
Function name: save_ems
Prototype: int save_ems(int handle, void far * buffer,
unsigned int size);
Use: save_ems moves data from the memory location specified by
buffer into the expanded memory location specified by
handle. save_ems returns 0 upon a successful memory move,
-1 if the attempt to move data failed.
Function name: load_ems
Prototype: int load_ems(int handle, void far * buffer,
unsigned int size);
Use: load_ems moves data from the memory location specified by
handle into buffer. load_ems returns 0 upon a successful
memory move, -1 if the attempt to move data failed.
Function name: pages_ems
Prototype: int pages_ems(int mode);
Use: pages_ems returns either the total number of pages in
expanded memory or the number of pages available to be
allocated. Each page is 16k bytes long. The number of
pages returned by pages_ems is determined by mode. A
value of 0 will return pages available and a value of 1
will return the total number of pages in expanded memory.
pages_ems will return -1 if the function failed.
Function name: ems_installed
Prototype: int emm_installed(void);
Use: emm_installed checks to see if the EMM has been installed
in memory. If the EMM has been located a value of 1 will
be returned, otherwise a value of 0 is returned.
DVMAM controller functions
--------------------------
These are the main functions used by DVMAM. DVMAM keeps track of all
the information required for use of the above functions. This information
includes handles, sizes and pointers. This makes allocation easier on the
programmer because all use of extended, expanded and conventional memory is
done by DVMAM.
Function name: alloc_mem
Prototype: int alloc_mem(int size);
Use: alloc_mem checks for memory available and attempts to
allocate to that memory. If the allocation is successful,
a block identification number is returned, otherwise -1
will be returned to alloc_mem.
Function name: dealloc_mem
Prototype: int dealloc_mem(int block);
Page 7
Use: dealloc_mem attempts to deallocate memory allocated with
alloc_mem. This will make it available for use elsewhere
in your program. dealloc_mem returns 0 upon successful
deallocation, -1 if the deallocation attempt failed.
Function name: save_memory
Prototype: int save_memory(int block);
Use: save_memory moves the data located in dvmam_dta into the
memory location and type specified by the block
identification number returned by alloc_mem. save_memory
returns 0 if the attempted move was successful, -1 if
the attempted move failed.
Function name: load_memory
Prototype: int load_memory(int block);
Use: load_memory moves data from the memory location and type
specified by the block identification number into
dvmam_dta. load_memory returns 0 if the attempted move
was successful, -1 if the attempted move failed.
Function name: bytes_available
Prototype: unsigned long bytes_available(void);
Use: bytes_available checks all memory types in use and
returns the total amount of memory available to be
allocated by alloc_mem.
Function name: bytes_total
Prototype: unsigned long bytes_total(void);
Use: bytes_total checks all memory types in use and returns
the total amount of memory in those memory types. This is
total system memory and is not the amount of memory that
can be used.
Function name: set_memory_usage
Prototype: void set_memory_usage(int usage);
Use: set_memory_usage informs DVMAM of which types of memory
you wish to attempt to use. By default DVMAM will attempt
to use conventional, expanded and extended memory. There
are four nyms associated with values that may be used to
determine which memory types to use:
NONE = 0
USE_CONV = 1
USE_EXT = 2
USE_EMS = 4
Examples: set_memory_usage(USE_CONV);
set_memory_usage(USE_EMS+USE_EXT);
Page 8
Examples continued..
set_memory_usage(USE_EXT+USE_CONV);
set_memory_usage(NONE);
Function name: memory_setup
Prototype: void memory_setup(unsigned int size);
Use: memory_setup prepares extended memory structures, DVMAM
structures and allocates memory to dvmam_dta. The amount
to memory allocated to dvmam_dta is specified by size.
Function name: memory_shutdown
Prototype: void memory_shutdown(void);
Use: memory_shutdown frees all memory in use by DVMAM
including dvmam_dta, extended, expanded and other
conventional memory.
How do I link the DVMAM library into my program?
------------------------------------------------
TURBO C Projects
----------------
TURBO C projects take out a majority of the worry about linking the
DVMAM library into your program if you prefer to use the integrated
environment. To create a project for TURBO C, simply make a text file with
the files:
DVMAMSTC.LIB
MYFILE.C
MYFILE.C is the filename of your program. In many cases there will be
more files that make up the entire program than just the one specified by
MYFILE.C. These files also need to be added to the project list.
Once the project file has been created the TURBO C environment needs
to know which project it is going to use to create the desired program.
Typing ALT-P to go to the project menu and entering the project name will
do this.
TURBO C command-line compiler
-----------------------------
If the environment is not used there are two other methods that may be
used to link the DVMAM library into your program. The first is by adding
the name DVMAMSTC.LIB to the list of command-line options with the TCC
command-line compiler. The second is using TLINK which should have come
with your TURBO C compiler.
Page 9
Using TCC is definitely the easier of the two methods as the default
libraries normally used with TURBO C are automatically included when TCC
attempts to link your file. This is a typical example of using TCC to
compile and link DVMAMSTC.LIB into your program
C:>TCC MYFILE.C DVMAMSTC.LIB
This simple example will compile MYFILE.C and attempt to link the
files MYFILE.OBJ (which is created by TCC) and DVMAMSTC.LIB with the
libraries that are normally used by TURBO C. It is important to make sure
that the memory model being used in MYFILE.C is the same as is used in
DVMAMSTC.LIB. The filename DVMAMSTC.LIB may be broken down as follows:
DVMAM S TC.LIB. The DVMAM naturally standing for DVMAM. S indicates small
memory model. For other memory models, C (compact), M (medium), L (large)
and H (huge) will be used. TC stands for TURBO C and the LIB indicates a
library file.
TLINK
-----
Attempting to link your program together by directly invoking TLINK is
definitely more difficult as ALL libraries must explicitly be specified. A
simplified example of using TLINK would be as follows:
TLINK MYFILE,MEMORY,,DVMAMSTC
TLINK will then attempt to link DVMAMSTC.LIB into the file MYFILE.OBJ
and create MEMORY.EXE. This would only work if no other functions other
than those in DVMAM which are written explicitly in assembler were to be
used (expanded and extended memory). Since DVMAM has been written both in
assembly and TURBO C many of the functions used in DVMAM use functions from
the standard TURBO C library. Those libraries may be specified on the
command line and linked in. A more complicated example would be:
TLINK MYFILE C0S,MEMORY,,DVMAMSTC EMU CS MATHS
TLINK would then attempt to link MYFILE.OBJ, C0S.OBJ, DVMAMSTC.LIB,
EMU.LIB, CS.LIB and MATHS.LIB together into an executable file called
MEMORY.EXE. It is critical that the file MYFILE is compiled and linked in
the same memory model as the libraries you intend to use. In the above
example CS.LIB, MATHS.LIB, DVMAMSTC.LIB and C0S.OBJ are all libraries that
use the small memory model.
Page 10
Thanks
------
Thank you for your interest in the Dynamic-Virtual Memory Allocation
Manager. We'd love to hear from you with your comments on DVMAM and any
suggestions you may have as to how to improve DVMAM. We realize that
programs may float around for many months before they fall into your hands.
Feel free to write at any time for information about other products by
R.C.B. Enterprises or for information about what is happening in the
development of a specific program. If you discover that the version of
DVMAM you are using has been upgraded since you received your demo version
you may request a demo be sent out to you for a $3 charge to cover copying
and postage. Our address is:
R.C.B. Enterprises, Team A
15 Central Way, #287
Kirkland, WA. 98033
Version 1.10 release
--------------------
Version 1.10 is virtually the same as version 1.00. It contains one
bug fix performs two more checks than the previous version.
The bug was in the deallocation of memory. Blocks deallocated were
deallocated, but not marked as so. So, depending on how much memory you
have in your machine, you would be able to allocate memory only a certain
number of times before you were unable to allocate. In the case of the main
testing computer with 2.2 megs, we were able to allocate 76 blocks before
all blocks were used. This bug is non-destructive and should not effect
users of version 1.0.
There are two more checks performed. One is that you cannot allocate
more memory to a block than is allocated to dvmam_dta. So if you allocated
16k to dvmam_dta, you could not allocate a block that was 32k.
The other check is on the boundaries in extended memory. It now floats
instead of staying in a stable position. This simply improves performance
of the extended memory engine.
Page 11
Dynamic-Virtual Memory Allocation Manager 1.10
Registration Form
Thank you for taking the time to register DVMAM
Company name: _________________________________________
User name: _________________________________________
Address: _________________________________________
_________________________________________
City,State,Zip: _________________________________________
Phone: (______) ______-_________ (in case there are questions about your
order)
Date of registration: ___________
Compiler: TURBO C [ ] TURBO PASCAL [ ] Microsoft C [ ]
Compiler version: ______________
I would like information about other products [ ]
==========================================================================
Number of copies desired at $35 (U.S. currency) per copy _______
$5 for shipping $ 5.00
(Washington residents add 8.1% sales tax) $ _______
Total amount enclosed $ _______
Payment type: ____ Money order/Cashiers check ____ VISA
____ Personal/Business check ____ Master Card
Please make checks payable to R.C.B. Enterprises. Personal and business
checks please allow at least 10 business days to clear.
Card number: ________________________ Signature: ________________________
Expiration date: __________________
Please send a copy of this registration form with registration payment
to:
R.C.B. Enterprises, Team A
15 Central Way, #287
Kirkland, WA. 98033
